Resize problem

Hi,

When I resize the installer window while in the packs panel, only the 
description pane gets taller/shorter. The package selection pane will 
only shrink, it will never grow taller than its initial height. When I 
resize the window while in this panel, it's because I want to see all 
the packs at the same time, not so much to make more room for the 
description. I suppose they should both grow proportionally.

Sandor Vroemisse

Re: Resize problem

_______________________________________________
izpack-devel mailing list
izpack-devel@...
https://lists.berlios.de/mailman/listinfo/izpack-devel

Re: Infrastructure: vote

> [ Question ]
>
> Should we investigate a move of some services to CodeHaus?

I vote for investigation. 

Re: Infrastructure: vote

Last call for the votes as it ends tonight 

Re: A few thoughts on the project infrastructures

Hi,

> I've been playing with an evaluation license of JIRA: this tool would
> be just great for managing efficiently the project (roadmap, tasks,
> RFEs, bugs, ...).

I think managing and especially bug tracking would be nice. Mail 
based managing won't be quite good.

> One possible solution would be to move the developer services to
> Codehaus: SVN, downloads, mailing-lists, JIRA, wiki.

Would it be possible move both web and developer service to one 
provider?

It might be worth of discussing with some developer and/or web 
service providers.

As Marc said in some mail the move must make carefully: IzPack 
should not disappear. There should always be some place where to 
find the product or project. At least saying: "we are moving" or 
something.

Regards,
Ari

Re: Infrastructure: vote

> [ Question ]
> 
> Should we investigate a move of some services to CodeHaus?

I will vote: yes.

Re: A few thoughts on the project infrastructures

Hi,

When you look for new places for the developer services could you 
check how they will view mail list messages and archive ones. 
Berlios will seem to view whole email address although they 
replace @ with " at ". I think this is not enough: spammers might 
take easily addresses and correct them programmatically. Some 
mail lists use "first.last <at> xxx" or "first.last <at> domain" or 
something like this.

Regards,
Ari

Infrastructures discussion summary

Hi everyone,

First of all I would like to thank all the people that have enriched  
the discussion 

The idea of investigating a move of the developer services to another  
provider (CodeHaus) has received positive feedback. Let me answer to  
some concerns that have been raised.

1. Visibility of the project

BerliOS is only hosting the developer services, while izpack.org is  
hosted on a web hosting provider for which I also host my blog (jpz- 
log.info) and izforge.com.

izpack.org will remain the public website / entry point to the  
project, so a move will never hamper the visibility.

I however envision switching it to WordPress (a very fine weblog  
system that is also good as a CMS). The goal is to make it more  
community-focused (with people being able to post news or edit  
content) and more streamlined than it currently is.

Codehaus provides a wiki (Confluence) which could be great to use as  
well for everything that doesn't fit on an external communication  
website (which izpack.org is there for).

The separation between izpack.org and the developer services is  
important to me. When I bought izpack.org so that the project has its  
own domain we didn't loose any pagerank and the likes (using  
redirections) 

2. If we switch...

...the BerliOS content will not disappear overnight  In fact me  
should keep it open for a while (but indicate that we have moved in  
case somebody gets there).

The move of the services will be careful planned so that people have  
enough time to migrate.

We could start using JIRA (issue tracking, project management) right  
off. CodeHaus provides a Confluence instance (a wiki) that we could  
use quickly as well.

The migration of SVN is an easy thing to do and we won't loose  
history. Everything is to have a good schedule.

Moving the mailing-lists should be done carefully. People need time  
to migrate. We even have the option of automatically migrating the  
email addresses. I'm not sure if the lists history can be migrated.  
It may be simpler to keep 'BerliOS-era' archives at BerliOS.

3. Mailing-lists anti-spamming

A good point, see http://archive.groovy.codehaus.org/dev to see what  
it looks like.

4. Migration redirects

This one had been raised by Marc. I hope that this email provides the  
answers that you were expecting 

5. What's next

I am going to contact the CodeHaus people this afternoon and see if  
they would accept us (they are very selective about the projects!).

I'll inform you of the outcome as soon as possible.

Cheers

Drop 1.4 compatibility?

Hi everyone,

I've been thinking about it for a while: what if we dropped 1.4
compatibility in the next releases?

We could still use Retroweaver to produce a 1.4-compatible version
(http://retroweaver.sourceforge.net/)

The thing is that I'm pretty sure that some panels require Java 5...
and those things are hard to track!

What do you think?

Cheers

xinclude - can't use include from within userInputSpec.xml (in installation time)

Hi All,

There is a problem with using xinclude feature when used
in userInputSpec.xml. The problem appears in installation-time,
when XIncludeXMLBuilder is unable to find fragments. They would
have to be placed outside of install.jar, to be accessible
in installation-time.

However, xinclude feature works fine for install.xml as fragments
are included/resolved during compilation time. UserInputSpec.xml
is not parsed in compile-time, but simply embedded into resources.

I have worked out a quick solution for it. It can be found
in the attachment. Tell me what do you think about it.
The solution is to modify XIncludeXMLBuilder, to be able
to check resources whether they contain referenced fragment.
Fragments have to be put in resources, and referenced using
/res/ prefix, as I didn't want to hard code this prefix into
XIncludeXMLBuilder.

One more time, tell me what do you think about this patch.

Regards,
Piotr Skowronek

Index: src/lib/net/n3/nanoxml/XIncludeXMLBuilder.java
===================================================================
--- src/lib/net/n3/nanoxml/XIncludeXMLBuilder.java	(revision 2031)
+++ src/lib/net/n3/nanoxml/XIncludeXMLBuilder.java	(working copy)
@@ -125,11 +125,18 @@
                 IXMLReader reader = null;
                 try {
                     reader = getReader(element);
-                } catch (Exception e) { // yes really catch all exceptions
-                    // ok failed to read from the location for some reason.
-                    // see if we have a fallback
-                    reader = handleFallback(element);
-                    usingFallback = true;
+                } catch (Exception ex1) { // yes really catch all exceptions
+                    
+                    try {
+                        // ok failed to read from the location for some reason.                    
+                        // see if we have a file in resource
+                        reader = getResourceReader(element);
+                    } catch (Exception ex2) {
+                        // ok failed to read from the location and resource for some reason.                    
+                        // see if we have a fallback
+                        reader = handleFallback(element);
+                        usingFallback = true;   
+                    }                    
                 }
                 String parse = element.getAttribute(PARSE_ATTRIB, "xml");
                 // process as text if we are not using our fallback and the parse
@@ -340,7 +347,45 @@
         }

         InputStream is = connection.getInputStream();
+        return getIXMLReader(element, is, url);
+    }

+    /**
+     * Return a reader for the specified resource {@link #INCLUDE_ELEMENT}. 
+     * The caller is responsible for closing the reader produced.
+     *
+     * @param element the include element to obtain a reader for
+     * @return a reader for the include element
+     * @throws XMLParseException if a problem occurs parsing the
+     *                           {@link #INCLUDE_ELEMENT}
+     * @throws IOException       if the resource location cannot be read
+     */
+    private IXMLReader getResourceReader(XMLElement element) throws XMLParseException, IOException {
+        String location = element.getAttribute(HREF_ATTRIB);
+        
+        URL url = XIncludeXMLBuilder.class.getResource(location);
+        InputStream is = XIncludeXMLBuilder.class.getResourceAsStream(location);
+        
+        if (is == null) {
+            throw new IOException("Resource not found: "+location);
+        }
+
+        return getIXMLReader(element, is, url);
+    }
+
+    /**
+     * Return a IXMLReader based on element's attributes, input stream, and url.
+     * 
+     * @param element the include element to obtain a reader for
+     * @param is the input stream 
+     * @param url the url 
+     * @return the IXMLReader
+     * @throws XMLParseException
+     * @throws IOException
+     */
+    private IXMLReader getIXMLReader(XMLElement element, InputStream is, URL url) 
+            throws XMLParseException, IOException {
+        
         InputStreamReader reader = null;
         // Only pay attention to the {@link #ENCODING_ATTRIB} if parse='text'  
         if (element.getAttribute(PARSE_ATTRIB, "xml").equals("text") &&

_______________________________________________
izpack-devel mailing list
izpack-devel@...
https://lists.berlios.de/mailman/listinfo/izpack-devel