Re: Fetching Artifacts From the Repository

[Emmanuel Lecharny <el...@gmail.com>]

Ole Ersoy a écrit :

>Hey Guys,
>
>Just a background quicky.  
>  
>
<snip/>

>rpm-apacheds-tools.sh
>
>located in the project server-installers under
>
>src/main/installers
>
>However installers is a non standard maven directory,
>so the whole directory is missing in the repository.
>
>QUESTION
>I wrote the process out in case there is a better one.
>If you like the process, then should we move the files
>in the installers directory to 
>src/main/resources?
>  
>
At this point, what I would say is : "it's up to you !" What we need 
first is a working rpm generation, but we should also be able to build 
installers for W$, Mac, etc.

The most important thing is that all the configuration files are stored 
in a common location, easy to find, even if it's not maven-standard. But 
if it's maven-standard too, then it's more than OK.

I'm sure that Alex have some clear ideas about installers, as he wrote 
them :)

Emmanuel

Re: Fetching Artifacts From the Repository

[Alex Karasulu <ao...@bellsouth.net>]

Sounds good.

Alex


Ole Ersoy wrote:
> I would think the Roadmap for our plugin should be a
> reflection of the design of the JPackage plugin.
> 
> Although we'd have to see whether the other installers
> benefit from the same type of flexibility incorporated
> into the JPackage plugin.
> 
> I think the Mac and Solaris ones will, but windows...
> 
> So the JPackage plugin is a subset of our plugin.
> 
> We just add more mojos and JET templates for other to 
> generate other installers.
> 
> I'm updating the design document for the JPackage
> plugin right now.
> 
> I'll post it on the wiki asap.
> 
> Then I'll be ready to start coding.
> 
> Then we can work together to see whether how we want
> the roadmap to look for the other installers.
> 
> Sounds ok?
> 
> Cheers,
> - Ole
> 
> 
> 
> --- Alex Karasulu <ao...@bellsouth.net> wrote:
> 
>> This is all good but what happens to our plugin?  Or
>> that is to be 
>> determined?
>>
>> Alex
>>
>> Ole Ersoy wrote:
>>> Aye that makes sense.  So you want to stuff things
>>>> into the 
>>>> src/main/resources area so they are bundled in
>> jars
>>>> and can be extracted 
>>>> from them once those jars are pulled down from
>>>> ibiblio or elsewhere?
>>>>
>>> Yap,
>>>
>>> So when the documentation for including the RPM
>> Plugin
>>> in a build is created, in there it will say that
>> the
>>> plugin fetches all the install files from the
>>> repository, so everything has to be in Maven
>> standard
>>> directories.
>>>
>>> That motivates projects to use the conventions
>>> provided by Maven.
>>>
>>> So Maven just stuffs everything in the Jar.
>>>
>>> The Plugin writes the Spec file per the
>> configuration
>>> instructions provided in a install.xml file and
>> puts
>>> it in the $rpmbuildenvironment/SPECS directory.
>>>
>>> Then it invokes 
>>>
>>> rpm -ba somedaemon.spec
>>>
>>> The commands for extracting 
>>> and building the install layout are in the spec
>> file.
>>> So really maven is done, and RPM takes care of the
>>> rest.
>>>
>>> - Ole 
>>>
>>> --- Alex Karasulu <ao...@bellsouth.net> wrote:
>>>
>>>> Ole Ersoy wrote:
>>>>> Yes I think what I'm saying is getting diluted
>>>> because
>>>>> you are used to thinking about how the current
>>>>> installer plugin works.
>>>>>
>>>>> OK - Pretend for a minute that there are no
>>>> installer
>>>>> plugins.  We are just getting started.
>>>> Okie.
>>>>
>>>>> All we have are maven java projects.
>>>>>
>>>>> Now we want to create a maven plugin that
>>>>> that we can use to create the RPM installer.
>>>>>
>>>>> However other projects have to be able to use it
>>>> to,
>>>>> and we want everyone using it the same way to
>> make
>>>>> cross project collaboration easier, etc.
>>>>>
>>>>> So we first make a generic decision with respect
>>>> to
>>>>> where the stuff the installer installs comes
>> from.
>>>> OK
>>>>
>>>>> We think that it's smart to pull all the
>> resources
>>>>> that the installer plugin needs from the maven
>>>>> repository, because that's where Maven puts
>>>> everything
>>>>> after various quality assurance tests pass.
>>>> Hmmm even non-java artifacts like shared libs and
>>>> stuff?  Meaning things 
>>>> where the extension is not .jar or .pom?  Cuz
>> maven
>>>> has serious issues 
>>>> with doing that I think.  Don't know fully though
>>>> but I'd give it a try.
>>>>
>>>>> So as as a rule we state that the Maven plugin
>> we
>>>> are
>>>>> creating pulls resources and artifacts from the
>>>>> Repository only.  We're going with the Maven
>>>>> Convention over configuration motto.
>>>> Coolio but you have to really experiment with
>> maven
>>>> to see if it can 
>>>> manage other artifact types besides jars and
>> poms.
>>>>> So the plugin does not care about stuff that
>>>> exists in
>>>>> maven projects sitting in a workspace or in a
>>>> version
>>>>> control system.
>>>>>
>>>>> It only cares about stuff that maven has
>> installed
>>>> in
>>>>> a local maven repository.
>>>>>
>>>>> Does that make more sense?
>>>> Aye that makes sense.  So you want to stuff
>> things
>>>> into the 
>>>> src/main/resources area so they are bundled in
>> jars
>>>> and can be extracted 
>>>> from them once those jars are pulled down from
>>>> ibiblio or elsewhere?
>>>>
>>>> Alex
>>>>
>>>
>>>
>>>  
>>>
> ____________________________________________________________________________________
>>> Want to start your own business? Learn how on
>> Yahoo! Small Business 
>>> (http://smallbusiness.yahoo.com) 
>>>
>>>
>>
> 
> 
> 
>  
> ____________________________________________________________________________________
> Want to start your own business? Learn how on Yahoo! Small Business 
> (http://smallbusiness.yahoo.com) 
> 
> 

Re: Fetching Artifacts From the Repository

[Ole Ersoy <ol...@yahoo.com>]

I would think the Roadmap for our plugin should be a
reflection of the design of the JPackage plugin.

Although we'd have to see whether the other installers
benefit from the same type of flexibility incorporated
into the JPackage plugin.

I think the Mac and Solaris ones will, but windows...

So the JPackage plugin is a subset of our plugin.

We just add more mojos and JET templates for other to 
generate other installers.

I'm updating the design document for the JPackage
plugin right now.

I'll post it on the wiki asap.

Then I'll be ready to start coding.

Then we can work together to see whether how we want
the roadmap to look for the other installers.

Sounds ok?

Cheers,
- Ole



--- Alex Karasulu <ao...@bellsouth.net> wrote:

> This is all good but what happens to our plugin?  Or
> that is to be 
> determined?
> 
> Alex
> 
> Ole Ersoy wrote:
> > Aye that makes sense.  So you want to stuff things
> >> into the 
> >> src/main/resources area so they are bundled in
> jars
> >> and can be extracted 
> >> from them once those jars are pulled down from
> >> ibiblio or elsewhere?
> >>
> > 
> > Yap,
> > 
> > So when the documentation for including the RPM
> Plugin
> > in a build is created, in there it will say that
> the
> > plugin fetches all the install files from the
> > repository, so everything has to be in Maven
> standard
> > directories.
> > 
> > That motivates projects to use the conventions
> > provided by Maven.
> > 
> > So Maven just stuffs everything in the Jar.
> > 
> > The Plugin writes the Spec file per the
> configuration
> > instructions provided in a install.xml file and
> puts
> > it in the $rpmbuildenvironment/SPECS directory.
> > 
> > Then it invokes 
> > 
> > rpm -ba somedaemon.spec
> > 
> > The commands for extracting 
> > and building the install layout are in the spec
> file.
> > 
> > So really maven is done, and RPM takes care of the
> > rest.
> > 
> > - Ole 
> > 
> > --- Alex Karasulu <ao...@bellsouth.net> wrote:
> > 
> >> Ole Ersoy wrote:
> >>> Yes I think what I'm saying is getting diluted
> >> because
> >>> you are used to thinking about how the current
> >>> installer plugin works.
> >>>
> >>> OK - Pretend for a minute that there are no
> >> installer
> >>> plugins.  We are just getting started.
> >> Okie.
> >>
> >>> All we have are maven java projects.
> >>>
> >>> Now we want to create a maven plugin that
> >>> that we can use to create the RPM installer.
> >>>
> >>> However other projects have to be able to use it
> >> to,
> >>> and we want everyone using it the same way to
> make
> >>> cross project collaboration easier, etc.
> >>>
> >>> So we first make a generic decision with respect
> >> to
> >>> where the stuff the installer installs comes
> from.
> >> OK
> >>
> >>> We think that it's smart to pull all the
> resources
> >>> that the installer plugin needs from the maven
> >>> repository, because that's where Maven puts
> >> everything
> >>> after various quality assurance tests pass.
> >> Hmmm even non-java artifacts like shared libs and
> >> stuff?  Meaning things 
> >> where the extension is not .jar or .pom?  Cuz
> maven
> >> has serious issues 
> >> with doing that I think.  Don't know fully though
> >> but I'd give it a try.
> >>
> >>> So as as a rule we state that the Maven plugin
> we
> >> are
> >>> creating pulls resources and artifacts from the
> >>> Repository only.  We're going with the Maven
> >>> Convention over configuration motto.
> >> Coolio but you have to really experiment with
> maven
> >> to see if it can 
> >> manage other artifact types besides jars and
> poms.
> >>
> >>> So the plugin does not care about stuff that
> >> exists in
> >>> maven projects sitting in a workspace or in a
> >> version
> >>> control system.
> >>>
> >>> It only cares about stuff that maven has
> installed
> >> in
> >>> a local maven repository.
> >>>
> >>> Does that make more sense?
> >> Aye that makes sense.  So you want to stuff
> things
> >> into the 
> >> src/main/resources area so they are bundled in
> jars
> >> and can be extracted 
> >> from them once those jars are pulled down from
> >> ibiblio or elsewhere?
> >>
> >> Alex
> >>
> > 
> > 
> > 
> >  
> >
>
____________________________________________________________________________________
> > Want to start your own business? Learn how on
> Yahoo! Small Business 
> > (http://smallbusiness.yahoo.com) 
> > 
> > 
> 
> 



 
____________________________________________________________________________________
Want to start your own business? Learn how on Yahoo! Small Business 
(http://smallbusiness.yahoo.com) 

Re: Fetching Artifacts From the Repository

[Alex Karasulu <ao...@bellsouth.net>]

This is all good but what happens to our plugin?  Or that is to be 
determined?

Alex

Ole Ersoy wrote:
> Aye that makes sense.  So you want to stuff things
>> into the 
>> src/main/resources area so they are bundled in jars
>> and can be extracted 
>> from them once those jars are pulled down from
>> ibiblio or elsewhere?
>>
> 
> Yap,
> 
> So when the documentation for including the RPM Plugin
> in a build is created, in there it will say that the
> plugin fetches all the install files from the
> repository, so everything has to be in Maven standard
> directories.
> 
> That motivates projects to use the conventions
> provided by Maven.
> 
> So Maven just stuffs everything in the Jar.
> 
> The Plugin writes the Spec file per the configuration
> instructions provided in a install.xml file and puts
> it in the $rpmbuildenvironment/SPECS directory.
> 
> Then it invokes 
> 
> rpm -ba somedaemon.spec
> 
> The commands for extracting 
> and building the install layout are in the spec file.
> 
> So really maven is done, and RPM takes care of the
> rest.
> 
> - Ole 
> 
> --- Alex Karasulu <ao...@bellsouth.net> wrote:
> 
>> Ole Ersoy wrote:
>>> Yes I think what I'm saying is getting diluted
>> because
>>> you are used to thinking about how the current
>>> installer plugin works.
>>>
>>> OK - Pretend for a minute that there are no
>> installer
>>> plugins.  We are just getting started.
>> Okie.
>>
>>> All we have are maven java projects.
>>>
>>> Now we want to create a maven plugin that
>>> that we can use to create the RPM installer.
>>>
>>> However other projects have to be able to use it
>> to,
>>> and we want everyone using it the same way to make
>>> cross project collaboration easier, etc.
>>>
>>> So we first make a generic decision with respect
>> to
>>> where the stuff the installer installs comes from.
>> OK
>>
>>> We think that it's smart to pull all the resources
>>> that the installer plugin needs from the maven
>>> repository, because that's where Maven puts
>> everything
>>> after various quality assurance tests pass.
>> Hmmm even non-java artifacts like shared libs and
>> stuff?  Meaning things 
>> where the extension is not .jar or .pom?  Cuz maven
>> has serious issues 
>> with doing that I think.  Don't know fully though
>> but I'd give it a try.
>>
>>> So as as a rule we state that the Maven plugin we
>> are
>>> creating pulls resources and artifacts from the
>>> Repository only.  We're going with the Maven
>>> Convention over configuration motto.
>> Coolio but you have to really experiment with maven
>> to see if it can 
>> manage other artifact types besides jars and poms.
>>
>>> So the plugin does not care about stuff that
>> exists in
>>> maven projects sitting in a workspace or in a
>> version
>>> control system.
>>>
>>> It only cares about stuff that maven has installed
>> in
>>> a local maven repository.
>>>
>>> Does that make more sense?
>> Aye that makes sense.  So you want to stuff things
>> into the 
>> src/main/resources area so they are bundled in jars
>> and can be extracted 
>> from them once those jars are pulled down from
>> ibiblio or elsewhere?
>>
>> Alex
>>
> 
> 
> 
>  
> ____________________________________________________________________________________
> Want to start your own business? Learn how on Yahoo! Small Business 
> (http://smallbusiness.yahoo.com) 
> 
> 

Re: Fetching Artifacts From the Repository

[Ole Ersoy <ol...@yahoo.com>]

Aye that makes sense.  So you want to stuff things
> into the 
> src/main/resources area so they are bundled in jars
> and can be extracted 
> from them once those jars are pulled down from
> ibiblio or elsewhere?
> 

Yap,

So when the documentation for including the RPM Plugin
in a build is created, in there it will say that the
plugin fetches all the install files from the
repository, so everything has to be in Maven standard
directories.

That motivates projects to use the conventions
provided by Maven.

So Maven just stuffs everything in the Jar.

The Plugin writes the Spec file per the configuration
instructions provided in a install.xml file and puts
it in the $rpmbuildenvironment/SPECS directory.

Then it invokes 

rpm -ba somedaemon.spec

The commands for extracting 
and building the install layout are in the spec file.

So really maven is done, and RPM takes care of the
rest.

- Ole 

--- Alex Karasulu <ao...@bellsouth.net> wrote:

> Ole Ersoy wrote:
> > Yes I think what I'm saying is getting diluted
> because
> > you are used to thinking about how the current
> > installer plugin works.
> > 
> > OK - Pretend for a minute that there are no
> installer
> > plugins.  We are just getting started.
> 
> Okie.
> 
> > All we have are maven java projects.
> > 
> > Now we want to create a maven plugin that
> > that we can use to create the RPM installer.
> > 
> > However other projects have to be able to use it
> to,
> > and we want everyone using it the same way to make
> > cross project collaboration easier, etc.
> > 
> > So we first make a generic decision with respect
> to
> > where the stuff the installer installs comes from.
> 
> OK
> 
> > We think that it's smart to pull all the resources
> > that the installer plugin needs from the maven
> > repository, because that's where Maven puts
> everything
> > after various quality assurance tests pass.
> 
> Hmmm even non-java artifacts like shared libs and
> stuff?  Meaning things 
> where the extension is not .jar or .pom?  Cuz maven
> has serious issues 
> with doing that I think.  Don't know fully though
> but I'd give it a try.
> 
> > So as as a rule we state that the Maven plugin we
> are
> > creating pulls resources and artifacts from the
> > Repository only.  We're going with the Maven
> > Convention over configuration motto.
> 
> Coolio but you have to really experiment with maven
> to see if it can 
> manage other artifact types besides jars and poms.
> 
> > So the plugin does not care about stuff that
> exists in
> > maven projects sitting in a workspace or in a
> version
> > control system.
> > 
> > It only cares about stuff that maven has installed
> in
> > a local maven repository.
> > 
> > Does that make more sense?
> 
> Aye that makes sense.  So you want to stuff things
> into the 
> src/main/resources area so they are bundled in jars
> and can be extracted 
> from them once those jars are pulled down from
> ibiblio or elsewhere?
> 
> Alex
> 



 
____________________________________________________________________________________
Want to start your own business? Learn how on Yahoo! Small Business 
(http://smallbusiness.yahoo.com) 

Re: Fetching Artifacts From the Repository

[Alex Karasulu <ao...@bellsouth.net>]

Ole Ersoy wrote:
> Yes I think what I'm saying is getting diluted because
> you are used to thinking about how the current
> installer plugin works.
> 
> OK - Pretend for a minute that there are no installer
> plugins.  We are just getting started.

Okie.

> All we have are maven java projects.
> 
> Now we want to create a maven plugin that
> that we can use to create the RPM installer.
> 
> However other projects have to be able to use it to,
> and we want everyone using it the same way to make
> cross project collaboration easier, etc.
> 
> So we first make a generic decision with respect to
> where the stuff the installer installs comes from.

OK

> We think that it's smart to pull all the resources
> that the installer plugin needs from the maven
> repository, because that's where Maven puts everything
> after various quality assurance tests pass.

Hmmm even non-java artifacts like shared libs and stuff?  Meaning things 
where the extension is not .jar or .pom?  Cuz maven has serious issues 
with doing that I think.  Don't know fully though but I'd give it a try.

> So as as a rule we state that the Maven plugin we are
> creating pulls resources and artifacts from the
> Repository only.  We're going with the Maven
> Convention over configuration motto.

Coolio but you have to really experiment with maven to see if it can 
manage other artifact types besides jars and poms.

> So the plugin does not care about stuff that exists in
> maven projects sitting in a workspace or in a version
> control system.
> 
> It only cares about stuff that maven has installed in
> a local maven repository.
> 
> Does that make more sense?

Aye that makes sense.  So you want to stuff things into the 
src/main/resources area so they are bundled in jars and can be extracted 
from them once those jars are pulled down from ibiblio or elsewhere?

Alex

Re: Fetching Artifacts From the Repository

[Ole Ersoy <ol...@yahoo.com>]

Yes I think what I'm saying is getting diluted because
you are used to thinking about how the current
installer plugin works.

OK - Pretend for a minute that there are no installer
plugins.  We are just getting started.

All we have are maven java projects.

Now we want to create a maven plugin that
that we can use to create the RPM installer.

However other projects have to be able to use it to,
and we want everyone using it the same way to make
cross project collaboration easier, etc.

So we first make a generic decision with respect to
where the stuff the installer installs comes from.

We think that it's smart to pull all the resources
that the installer plugin needs from the maven
repository, because that's where Maven puts everything
after various quality assurance tests pass.

So as as a rule we state that the Maven plugin we are
creating pulls resources and artifacts from the
Repository only.  We're going with the Maven
Convention over configuration motto.

So the plugin does not care about stuff that exists in
maven projects sitting in a workspace or in a version
control system.

It only cares about stuff that maven has installed in
a local maven repository.

Does that make more sense?

Ole

--- Alex Karasulu <ao...@bellsouth.net> wrote:

> Ole Ersoy wrote:
> > Alex:
> > Hmmm why resources? The server-installers module
> is
> > not intended to 
> > build a jar that has resources in it.
> > 
> > Ole:
> > The JPackage plugin wants to fetch the 
> > 
> > rpm-apacheds-tools.sh
> > 
> > file from the Maven repository.
> 
> What does the JPackage plugin have to do with this
> shell script?  Sorry 
> I must have lost a step here?
> 
> > It's not there because it's not in a standard
> maven
> > directory, so maven does not know to package and
> > install it as part of the created jar artifact
> during
> > the build.
> 
> Ok I'm confused totally now.  The server-installers
> maven module does 
> not generate a jar that we deploy to the maven
> repository.
> 
> It is just there to build ApacheDS installers.  The
> jar that would be 
> generated by server-installers is empty and is not a
> part of ApacheDS.
> 
> > What I'll do is create a temporary
> installer-resources
> > project with the needed files in the resources
> > directory.
> 
> I don't understand.  Which plugin are talking about
> now: the daemon 
> plugin or some other JPackage plugin?
> 
> > Then both installers are happy, but now we have
> two
> > copies floating around, which is less than ideal
> for
> > maintainence purposes, so later a common source
> for
> > both installer plugins should be created.
> > 
> > So that's the plan, unless making the change to
> the
> > current installer plugin takes two seconds, then I
> > won't have to mess with the alternative resources
> > project.
> 
> Are you trying to do something with another JPackage
> plugin someone else 
> has written?
> 
> Alex
> 



 
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates 
(http://voice.yahoo.com)

Re: Fetching Artifacts From the Repository

[Alex Karasulu <ao...@bellsouth.net>]

Ole Ersoy wrote:
> Alex:
> Hmmm why resources? The server-installers module is
> not intended to 
> build a jar that has resources in it.
> 
> Ole:
> The JPackage plugin wants to fetch the 
> 
> rpm-apacheds-tools.sh
> 
> file from the Maven repository.

What does the JPackage plugin have to do with this shell script?  Sorry 
I must have lost a step here?

> It's not there because it's not in a standard maven
> directory, so maven does not know to package and
> install it as part of the created jar artifact during
> the build.

Ok I'm confused totally now.  The server-installers maven module does 
not generate a jar that we deploy to the maven repository.

It is just there to build ApacheDS installers.  The jar that would be 
generated by server-installers is empty and is not a part of ApacheDS.

> What I'll do is create a temporary installer-resources
> project with the needed files in the resources
> directory.

I don't understand.  Which plugin are talking about now: the daemon 
plugin or some other JPackage plugin?

> Then both installers are happy, but now we have two
> copies floating around, which is less than ideal for
> maintainence purposes, so later a common source for
> both installer plugins should be created.
> 
> So that's the plan, unless making the change to the
> current installer plugin takes two seconds, then I
> won't have to mess with the alternative resources
> project.

Are you trying to do something with another JPackage plugin someone else 
has written?

Alex

Re: Fetching Artifacts From the Repository

[Ole Ersoy <ol...@yahoo.com>]

Alex:
Hmmm why resources? The server-installers module is
not intended to 
build a jar that has resources in it.

Ole:
The JPackage plugin wants to fetch the 

rpm-apacheds-tools.sh

file from the Maven repository.

It's not there because it's not in a standard maven
directory, so maven does not know to package and
install it as part of the created jar artifact during
the build.

What I'll do is create a temporary installer-resources
project with the needed files in the resources
directory.

Then both installers are happy, but now we have two
copies floating around, which is less than ideal for
maintainence purposes, so later a common source for
both installer plugins should be created.

So that's the plan, unless making the change to the
current installer plugin takes two seconds, then I
won't have to mess with the alternative resources
project.

Cheers,
- Ole




--- Alex Karasulu <ao...@bellsouth.net> wrote:

> Emmanuel Lecharny wrote:
> > Ole Ersoy a écrit :
> > 
> >> Hey Guys,
> >>
> >> Just a background quicky.   
> >>
> > <snip/>
> > 
> >> rpm-apacheds-tools.sh
> >>
> >> located in the project server-installers under
> >>
> >> src/main/installers
> >>
> >> However installers is a non standard maven
> directory,
> >> so the whole directory is missing in the
> repository.
> 
> THis is where the maven plugin looks for installer
> stuff.  It could be 
> elsewhere.
> 
> >> QUESTION
> >> I wrote the process out in case there is a better
> one.
> >> If you like the process, then should we move the
> files
> >> in the installers directory to
> src/main/resources?
> 
> Hmmm why resources? The server-installers module is
> not intended to 
> build a jar that has resources in it.
> 
> > At this point, what I would say is : "it's up to
> you !" What we need 
> > first is a working rpm generation, but we should
> also be able to build 
> > installers for W$, Mac, etc.
> > 
> > The most important thing is that all the
> configuration files are stored 
> > in a common location, easy to find, even if it's
> not maven-standard. But 
> > if it's maven-standard too, then it's more than
> OK.
> > 
> > I'm sure that Alex have some clear ideas about
> installers, as he wrote 
> > them :)
> 
> Yep I've been talking to Ole on IM a bit.  Wish it
> was on list though so 
> we could have a better trail of this stuff.
> 
> Ole,
> 
> Please svn cp (branch) the code into your private
> area and demonstrate 
> what you're thinking.
> 
> Show us and let's figure out what to do next.  Right
> now do you have a 
> good understanding of what the maven installer
> plugin is trying to do?
> 
> Did you try using it?
> 
> We probably discussed taking these steps to get more
> familiar with it on 
> IM.  But just gimme an update.
> 
> Thanks,
> Alex
> 
> 
> 



 
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups 
(http://groups.yahoo.com)

Re: Fetching Artifacts From the Repository

[Alex Karasulu <ao...@bellsouth.net>]

Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
> 
>> Hey Guys,
>>
>> Just a background quicky.   
>>
> <snip/>
> 
>> rpm-apacheds-tools.sh
>>
>> located in the project server-installers under
>>
>> src/main/installers
>>
>> However installers is a non standard maven directory,
>> so the whole directory is missing in the repository.

THis is where the maven plugin looks for installer stuff.  It could be 
elsewhere.

>> QUESTION
>> I wrote the process out in case there is a better one.
>> If you like the process, then should we move the files
>> in the installers directory to src/main/resources?

Hmmm why resources? The server-installers module is not intended to 
build a jar that has resources in it.

> At this point, what I would say is : "it's up to you !" What we need 
> first is a working rpm generation, but we should also be able to build 
> installers for W$, Mac, etc.
> 
> The most important thing is that all the configuration files are stored 
> in a common location, easy to find, even if it's not maven-standard. But 
> if it's maven-standard too, then it's more than OK.
> 
> I'm sure that Alex have some clear ideas about installers, as he wrote 
> them :)

Yep I've been talking to Ole on IM a bit.  Wish it was on list though so 
we could have a better trail of this stuff.

Ole,

Please svn cp (branch) the code into your private area and demonstrate 
what you're thinking.

Show us and let's figure out what to do next.  Right now do you have a 
good understanding of what the maven installer plugin is trying to do?

Did you try using it?

We probably discussed taking these steps to get more familiar with it on 
IM.  But just gimme an update.

Thanks,
Alex