You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2006/02/19 22:39:56 UTC

[status] Installers (Inno, RPM, Pkg, IzPack)

Hi all,

This is for those anxiously awaiting an installer.  I think we have 
something better than expected.

I'm almost done building a maven plugin which generates installers for a 
project whose final product is a UNIX daemon or a Windows service using 
jakarta commons daemon jsvc and procrun respectively.  The plugin will 
generate multiple installers when asked for a project.  We're using it 
already for ApacheDS and we have generalized it for any server 
application.  It should be ready right after the soon to arrive 1.0-RC1 
release.  The plugin has rough edges but we should be fine making it work.

Here's the URL for it now.  This might move over to the maven repo at 
some point though (after I clean it up a bit):

    http://svn.apache.org/repos/asf/directory/trunks/daemon/

Here's what some generated installers look like using apacheds as an 
example:

    http://people.apache.org/~akarasulu/apacheds/

Alex


Re: [status] Installers (Inno, RPM, Pkg, IzPack)

Posted by "Richard S. Hall" <he...@ungoverned.org>.
This sounds excellent. I can't wait until we can put it to the test for 
Felix.

-> richard

Alex Karasulu wrote:
> Hi all,
>
> This is for those anxiously awaiting an installer.  I think we have 
> something better than expected.
>
> I'm almost done building a maven plugin which generates installers for 
> a project whose final product is a UNIX daemon or a Windows service 
> using jakarta commons daemon jsvc and procrun respectively.  The 
> plugin will generate multiple installers when asked for a project.  
> We're using it already for ApacheDS and we have generalized it for any 
> server application.  It should be ready right after the soon to arrive 
> 1.0-RC1 release.  The plugin has rough edges but we should be fine 
> making it work.
>
> Here's the URL for it now.  This might move over to the maven repo at 
> some point though (after I clean it up a bit):
>
>    http://svn.apache.org/repos/asf/directory/trunks/daemon/
>
> Here's what some generated installers look like using apacheds as an 
> example:
>
>    http://people.apache.org/~akarasulu/apacheds/
>
> Alex
>
>

Re[2]: [status] Installers (Inno, RPM, Pkg, IzPack)

Posted by Peter Kriens <Pe...@aQute.se>.
Great, let me know when I can point to something!

Kind regards,

     Peter Kriens
     
AK> Peter Kriens wrote:
>> Any progress? I am working on the OSGi tutorial and would love to be
>> able to point to an installer page ... Preferably with the option to
>> run it as a service/deamon
>>   
AK> Peter,

AK> I've completed the plugin and now will mavenize felix as best as I can.
AK> Then I will use this plugin to build felix and the installers for it.
AK> It will build the installer to make the application into a 
AK> service/daemon as it did for apacheds.


AK> Alex


-- 
Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599


Re: [status] Installers (Inno, RPM, Pkg, IzPack)

Posted by Alex Karasulu <ao...@bellsouth.net>.
Peter Kriens wrote:
> Any progress? I am working on the OSGi tutorial and would love to be
> able to point to an installer page ... Preferably with the option to
> run it as a service/deamon
>   
Peter,

I've completed the plugin and now will mavenize felix as best as I can.  
Then I will use this plugin to build felix and the installers for it.  
It will build the installer to make the application into a 
service/daemon as it did for apacheds.


Alex


Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by Upayavira <uv...@odoko.co.uk>.
Alex Karasulu wrote:
> Upayavira wrote:
>> Richard S. Hall wrote:
>>  
>>> Comments and suggestions are encouraged. Let's get this thing out the
>>> door ASAP.
>>>     
>>
>>   
> There may be a couple of rules that I'm not remembering.  Regardless I'd
> sanity check this with Noel just to be sure.
>> As I understand it, the main thing is that we mark it as 'incubating' in
>> the relevant places, e.g. in the filename.
>>
>> You get a release zip/tgz ready, I'll work out what needs to be done to
>> do it properly :-)
>>   
> Is this guy a great mentor or what?  Thanks U!

Hey, I'm only doing the easy bits. Leaving the difficult bits (like
actually understanding OSGi) to the clever people :-)

Upayavira

Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by Alex Karasulu <ao...@bellsouth.net>.
Upayavira wrote:
> Richard S. Hall wrote:
>   
>> Comments and suggestions are encouraged. Let's get this thing out the
>> door ASAP.
>>     
>
>   
There may be a couple of rules that I'm not remembering.  Regardless I'd 
sanity check this with Noel just to be sure.
> As I understand it, the main thing is that we mark it as 'incubating' in
> the relevant places, e.g. in the filename.
>
> You get a release zip/tgz ready, I'll work out what needs to be done to
> do it properly :-)
>   
Is this guy a great mentor or what?  Thanks U!

Alex



Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> I think Alex was pointing to example installers for Directory, not
> Felix, but that does raise an issue that I have been meaning to post for
> a week or so now.
> 
> I think it is very important that we get an easily
> downloaded/installable release of Felix out the door as soon as
> possible...actually, it is long overdue. :-(
> 
> Of the outstanding issues for Felix, my original thinking was that I
> wanted to target re-enabling security before making a public release.
> However, my mind has been changed on this and I now think we should
> target fixing security in the next public release.
> 
> I think we are ready with a stable, usable Felix release right now. In
> the last two months there have been a lot of changes to Felix, such as:
> 
>    * Complete refactoring of the Module Loader layer to provide better
>      modularity abstractions to support OSGi R4 features; there are
>      still a few more things to be done here, but overall it is in good
>      shape.
>    * Implemented support for directories on the class path.
>    * Implemented support for Bundle.getEntry()/getEntryPaths().
>    * Implemented support for installing bundles by reference and as
>      exploded JAR files.
>    * Improved several concurrency issues to lessen the possibility of
>      deadlocks.
>    * Fixed some low-level bugs/issues, some of which were around since
>      the Oscar days, like improperly handling the order of bundle class
>      path entries and ensuring that embedded JAR names do not clash.
>    * Added many minor bug fixes too.
> 
> And these changes are only in the last two months, there are many more
> improvements before then (like the rewriting of the URL Handlers service
> to support multiple framework instances). I am confident to say that
> Felix is ready for more wide-scale usage. This means that we need to
> make a public release.
> 
> Currently, Felix reports itself as 0.7.0...I think we should follow a
> release model where odd numbered point releases are experimental and
> even numbered point releases are stable. I propose that we declare the
> next release to be 0.8.0, with the subsequent development occurring in
> 0.9.0, followed by the 1.0.0 release.
> 
> I have one outstanding thing that I would like to commit for the 0.8.0
> release, which is some experimentation that I have been doing with OBR.
> This should be done within a week (unfortunately, I have had some other
> priorities or else this would be done already), but we could even go
> ahead without it.
> 
> If people have familiarity with making releases here at Apache, your
> input would be greatly appreciated, because this is all new to me.
> 
> Comments and suggestions are encouraged. Let's get this thing out the
> door ASAP.

As I understand it, the main thing is that we mark it as 'incubating' in
the relevant places, e.g. in the filename.

You get a release zip/tgz ready, I'll work out what needs to be done to
do it properly :-)

Regards, Upayavira


Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Alex Karasulu wrote:
>> Richard S. Hall wrote:
>>
>>>
>> Like makes perfect sense.
> Jeeze that's some kind of spelling error.  Sorry meant to say "That 
> makes sense." but the sentence did not.

I just assumed you were using Valley speak..."you know, like, makes 
perfect sense."  ;-)

-> richard

Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by Alex Karasulu <ao...@bellsouth.net>.
Alex Karasulu wrote:
> Richard S. Hall wrote:
>
>>
> Like makes perfect sense.
Jeeze that's some kind of spelling error.  Sorry meant to say "That 
makes sense." but the sentence did not.

Alex


Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Started playing in my sandbox.  Will attempt some mavenization of what 
> you have in the trunk.  I'm splitting things up now to abid by the one 
> module one artifact principal behind maven.  Got a handful of tiny 
> issues but I'll find a quick fix for it then ask questions later :).

Great. Make sure you re-read this message:

    
http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200602.mbox/%3c43F5990B.5070708@ungoverned.org%3e

Since it talks about the current structure of the framework subproject.

Thanks.

-> richard

Re: Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
...
> I think it is very important that we get an easily 
> downloaded/installable release of Felix out the door as soon as 
> possible...actually, it is long overdue. :-(
+1
...
> And these changes are only in the last two months, there are many more 
> improvements before then (like the rewriting of the URL Handlers 
> service to support multiple framework instances). I am confident to 
> say that Felix is ready for more wide-scale usage. This means that we 
> need to make a public release.
>
> Currently, Felix reports itself as 0.7.0...I think we should follow a 
> release model where odd numbered point releases are experimental and 
> even numbered point releases are stable. I propose that we declare the 
> next release to be 0.8.0, with the subsequent development occurring in 
> 0.9.0, followed by the 1.0.0 release.
>
Like makes perfect sense.
> If people have familiarity with making releases here at Apache, your 
> input would be greatly appreciated, because this is all new to me.
I can lend a hand with the maven and distribution aspects. To a large 
degree the plugin will handle most of the packaging in various formats 
for us. 
> Comments and suggestions are encouraged. Let's get this thing out the 
> door ASAP.
+1

Started playing in my sandbox.  Will attempt some mavenization of what 
you have in the trunk.  I'm splitting things up now to abid by the one 
module one artifact principal behind maven.  Got a handful of tiny 
issues but I'll find a quick fix for it then ask questions later :).

Alex


Initial Felix release (was Re: [status] Installers (Inno, RPM, Pkg, IzPack))

Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think Alex was pointing to example installers for Directory, not 
Felix, but that does raise an issue that I have been meaning to post for 
a week or so now.

I think it is very important that we get an easily 
downloaded/installable release of Felix out the door as soon as 
possible...actually, it is long overdue. :-(

Of the outstanding issues for Felix, my original thinking was that I 
wanted to target re-enabling security before making a public release. 
However, my mind has been changed on this and I now think we should 
target fixing security in the next public release.

I think we are ready with a stable, usable Felix release right now. In 
the last two months there have been a lot of changes to Felix, such as:

    * Complete refactoring of the Module Loader layer to provide better
      modularity abstractions to support OSGi R4 features; there are
      still a few more things to be done here, but overall it is in good
      shape.
    * Implemented support for directories on the class path.
    * Implemented support for Bundle.getEntry()/getEntryPaths().
    * Implemented support for installing bundles by reference and as
      exploded JAR files.
    * Improved several concurrency issues to lessen the possibility of
      deadlocks.
    * Fixed some low-level bugs/issues, some of which were around since
      the Oscar days, like improperly handling the order of bundle class
      path entries and ensuring that embedded JAR names do not clash.
    * Added many minor bug fixes too.

And these changes are only in the last two months, there are many more 
improvements before then (like the rewriting of the URL Handlers service 
to support multiple framework instances). I am confident to say that 
Felix is ready for more wide-scale usage. This means that we need to 
make a public release.

Currently, Felix reports itself as 0.7.0...I think we should follow a 
release model where odd numbered point releases are experimental and 
even numbered point releases are stable. I propose that we declare the 
next release to be 0.8.0, with the subsequent development occurring in 
0.9.0, followed by the 1.0.0 release.

I have one outstanding thing that I would like to commit for the 0.8.0 
release, which is some experimentation that I have been doing with OBR. 
This should be done within a week (unfortunately, I have had some other 
priorities or else this would be done already), but we could even go 
ahead without it.

If people have familiarity with making releases here at Apache, your 
input would be greatly appreciated, because this is all new to me.

Comments and suggestions are encouraged. Let's get this thing out the 
door ASAP.

-> richard

Peter Kriens wrote:
> Any progress? I am working on the OSGi tutorial and would love to be
> able to point to an installer page ... Preferably with the option to
> run it as a service/deamon
>
> Kind regards,
>
>      Peter Kriens
>      
> AK> Hi all,
>
> AK> This is for those anxiously awaiting an installer.  I think we have 
> AK> something better than expected.
>
> AK> I'm almost done building a maven plugin which generates installers for a
> AK> project whose final product is a UNIX daemon or a Windows service using
> AK> jakarta commons daemon jsvc and procrun respectively.  The plugin will
> AK> generate multiple installers when asked for a project.  We're using it
> AK> already for ApacheDS and we have generalized it for any server 
> AK> application.  It should be ready right after the soon to arrive 1.0-RC1
> AK> release.  The plugin has rough edges but we should be fine making it work.
>
> AK> Here's the URL for it now.  This might move over to the maven repo at 
> AK> some point though (after I clean it up a bit):
>
> AK>     http://svn.apache.org/repos/asf/directory/trunks/daemon/
>
> AK> Here's what some generated installers look like using apacheds as an 
> AK> example:
>
> AK>     http://people.apache.org/~akarasulu/apacheds/
>
> AK> Alex
>
>
>   

Re: [status] Installers (Inno, RPM, Pkg, IzPack)

Posted by Peter Kriens <Pe...@aQute.se>.
Any progress? I am working on the OSGi tutorial and would love to be
able to point to an installer page ... Preferably with the option to
run it as a service/deamon

Kind regards,

     Peter Kriens
     
AK> Hi all,

AK> This is for those anxiously awaiting an installer.  I think we have 
AK> something better than expected.

AK> I'm almost done building a maven plugin which generates installers for a
AK> project whose final product is a UNIX daemon or a Windows service using
AK> jakarta commons daemon jsvc and procrun respectively.  The plugin will
AK> generate multiple installers when asked for a project.  We're using it
AK> already for ApacheDS and we have generalized it for any server 
AK> application.  It should be ready right after the soon to arrive 1.0-RC1
AK> release.  The plugin has rough edges but we should be fine making it work.

AK> Here's the URL for it now.  This might move over to the maven repo at 
AK> some point though (after I clean it up a bit):

AK>     http://svn.apache.org/repos/asf/directory/trunks/daemon/

AK> Here's what some generated installers look like using apacheds as an 
AK> example:

AK>     http://people.apache.org/~akarasulu/apacheds/

AK> Alex


-- 
Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599