[VFS] Fix up pom so it works with Commons release profile

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[VFS] Fix up pom so it works with Commons release profile

sebb-2-2
At present, the VFS poms use the "apache-release" profile from the
Apache pom, and override some bits of it that don't suit Commons.

However, this is also done by the Commons parent pom which provides
its own "release" profile.

This is not ideal as VFS uses a different process for releasing code
from all other Commons components.

VFS is a multi-module project, which makes it a bit trickier to deal
with assemblies etc.

However as far as I can tell, it is relatively simple to fix VFS.

Change VFS parent pom to disable the assembly plugin for itself and
all inheriting poms

Change VFS distribution pom to re-enable the assembly plugin and
change the profile "apache-release" to "release"

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

garydgregory
Sebb,

Please modify the POMs and whatever else as you see fit.

It sure would be nice to release 2.1.

Gary


On Thu, Jan 16, 2014 at 7:22 PM, sebb <[hidden email]> wrote:

> At present, the VFS poms use the "apache-release" profile from the
> Apache pom, and override some bits of it that don't suit Commons.
>
> However, this is also done by the Commons parent pom which provides
> its own "release" profile.
>
> This is not ideal as VFS uses a different process for releasing code
> from all other Commons components.
>
> VFS is a multi-module project, which makes it a bit trickier to deal
> with assemblies etc.
>
> However as far as I can tell, it is relatively simple to fix VFS.
>
> Change VFS parent pom to disable the assembly plugin for itself and
> all inheriting poms
>
> Change VFS distribution pom to re-enable the assembly plugin and
> change the profile "apache-release" to "release"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

garydgregory
On Thu, Jan 16, 2014 at 7:49 PM, Gary Gregory <[hidden email]>wrote:

> Sebb,
>
> Please modify the POMs and whatever else as you see fit.
>
> It sure would be nice to release 2.1.
>

Sebb,

When do you think you'll be able to put time in? The multi-module stuff is
daunting. I just RM'd a release of HttpCommons HttpClient and it would not
have been possible without the wiki docs.

Thank you,
Gary



>
> Gary
>
>
> On Thu, Jan 16, 2014 at 7:22 PM, sebb <[hidden email]> wrote:
>
>> At present, the VFS poms use the "apache-release" profile from the
>> Apache pom, and override some bits of it that don't suit Commons.
>>
>> However, this is also done by the Commons parent pom which provides
>> its own "release" profile.
>>
>> This is not ideal as VFS uses a different process for releasing code
>> from all other Commons components.
>>
>> VFS is a multi-module project, which makes it a bit trickier to deal
>> with assemblies etc.
>>
>> However as far as I can tell, it is relatively simple to fix VFS.
>>
>> Change VFS parent pom to disable the assembly plugin for itself and
>> all inheriting poms
>>
>> Change VFS distribution pom to re-enable the assembly plugin and
>> change the profile "apache-release" to "release"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

sebb-2-2
On 21 January 2014 03:21, Gary Gregory <[hidden email]> wrote:

> On Thu, Jan 16, 2014 at 7:49 PM, Gary Gregory <[hidden email]>wrote:
>
>> Sebb,
>>
>> Please modify the POMs and whatever else as you see fit.
>>
>> It sure would be nice to release 2.1.
>>
>
> Sebb,
>
> When do you think you'll be able to put time in? The multi-module stuff is
> daunting. I just RM'd a release of HttpCommons HttpClient and it would not
> have been possible without the wiki docs.

I have done some work on this.I can fix up the poms so that the
Commons "release" profile works.
And it looks like the distribution module is not really needed. The
assembly plugin can be run from the top level pom.

I'm wondering whether VFS really needs to use multiple modules at all.

The examples could certainly be merged into the main module, and the
distribution module is not really needed.
That just leaves the sandbox module.

Does the sandbox module have any use as part of the proper component?
It does not seem to be included in any releases - it is only present in SVN.
Would it be better as an actual sandbox component?
Or if the classes are useful, perhaps they should be merged into core?

Note that Commons Net does not use modules, but does release its
examples separately, if that was still required.

> Thank you,
> Gary
>
>
>
>>
>> Gary
>>
>>
>> On Thu, Jan 16, 2014 at 7:22 PM, sebb <[hidden email]> wrote:
>>
>>> At present, the VFS poms use the "apache-release" profile from the
>>> Apache pom, and override some bits of it that don't suit Commons.
>>>
>>> However, this is also done by the Commons parent pom which provides
>>> its own "release" profile.
>>>
>>> This is not ideal as VFS uses a different process for releasing code
>>> from all other Commons components.
>>>
>>> VFS is a multi-module project, which makes it a bit trickier to deal
>>> with assemblies etc.
>>>
>>> However as far as I can tell, it is relatively simple to fix VFS.
>>>
>>> Change VFS parent pom to disable the assembly plugin for itself and
>>> all inheriting poms
>>>
>>> Change VFS distribution pom to re-enable the assembly plugin and
>>> change the profile "apache-release" to "release"
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

garydgregory
On Tue, Jan 21, 2014 at 11:10 AM, sebb <[hidden email]> wrote:

> On 21 January 2014 03:21, Gary Gregory <[hidden email]> wrote:
> > On Thu, Jan 16, 2014 at 7:49 PM, Gary Gregory <[hidden email]
> >wrote:
> >
> >> Sebb,
> >>
> >> Please modify the POMs and whatever else as you see fit.
> >>
> >> It sure would be nice to release 2.1.
> >>
> >
> > Sebb,
> >
> > When do you think you'll be able to put time in? The multi-module stuff
> is
> > daunting. I just RM'd a release of HttpCommons HttpClient and it would
> not
> > have been possible without the wiki docs.
>
> I have done some work on this.I can fix up the poms so that the
> Commons "release" profile works.
>

Thank you.


> And it looks like the distribution module is not really needed. The
> assembly plugin can be run from the top level pom.
>
> I'm wondering whether VFS really needs to use multiple modules at all.
>

Probably not.


>
> The examples could certainly be merged into the main module,


I imagine they would then end up in the test jar.


> and the
> distribution module is not really needed.
> That just leaves the sandbox module.
>
> Does the sandbox module have any use as part of the proper component?
>

These are works in progress or works that depend on jars with third party
incompatible licensing. Or perhaps works that are hard to test.

It does not seem to be included in any releases - it is only present in SVN.
>

Right.


> Would it be better as an actual sandbox component?
>

Depending on the licensing issue, they could be folded in the test jar.


> Or if the classes are useful, perhaps they should be merged into core?
>

As noted above it depends on what to do with code that depends on a third
party jar that has an incompatible license. The Java code is ASL 2 IIRC so
the issue is whether it is OK to distribute code that depends on a third
party jar which may have an incompatible license.

Gary

>
> Note that Commons Net does not use modules, but does release its
> examples separately, if that was still required.
>
> > Thank you,
> > Gary
> >
> >
> >
> >>
> >> Gary
> >>
> >>
> >> On Thu, Jan 16, 2014 at 7:22 PM, sebb <[hidden email]> wrote:
> >>
> >>> At present, the VFS poms use the "apache-release" profile from the
> >>> Apache pom, and override some bits of it that don't suit Commons.
> >>>
> >>> However, this is also done by the Commons parent pom which provides
> >>> its own "release" profile.
> >>>
> >>> This is not ideal as VFS uses a different process for releasing code
> >>> from all other Commons components.
> >>>
> >>> VFS is a multi-module project, which makes it a bit trickier to deal
> >>> with assemblies etc.
> >>>
> >>> However as far as I can tell, it is relatively simple to fix VFS.
> >>>
> >>> Change VFS parent pom to disable the assembly plugin for itself and
> >>> all inheriting poms
> >>>
> >>> Change VFS distribution pom to re-enable the assembly plugin and
> >>> change the profile "apache-release" to "release"
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: [hidden email] | [hidden email]
> >> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >>
> >
> >
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

sebb-2-2
On 21 January 2014 16:28, Gary Gregory <[hidden email]> wrote:

> On Tue, Jan 21, 2014 at 11:10 AM, sebb <[hidden email]> wrote:
>
>> On 21 January 2014 03:21, Gary Gregory <[hidden email]> wrote:
>> > On Thu, Jan 16, 2014 at 7:49 PM, Gary Gregory <[hidden email]
>> >wrote:
>> >
>> >> Sebb,
>> >>
>> >> Please modify the POMs and whatever else as you see fit.
>> >>
>> >> It sure would be nice to release 2.1.
>> >>
>> >
>> > Sebb,
>> >
>> > When do you think you'll be able to put time in? The multi-module stuff
>> is
>> > daunting. I just RM'd a release of HttpCommons HttpClient and it would
>> not
>> > have been possible without the wiki docs.
>>
>> I have done some work on this.I can fix up the poms so that the
>> Commons "release" profile works.
>>
>
> Thank you.
>
>
>> And it looks like the distribution module is not really needed. The
>> assembly plugin can be run from the top level pom.
>>
>> I'm wondering whether VFS really needs to use multiple modules at all.
>>
>
> Probably not.
>
>
>>
>> The examples could certainly be merged into the main module,
>
>
> I imagine they would then end up in the test jar.
>

Not necessarily; that depends on how the pom is set up and where the
code is moved.

I don't think it makes sense to put examples in the test jar.

The example sources can be usefully included in the binary archive.

Whether there is any need for example binaries depends on whether the
examples actually work as is.
For example, the Net examples can be run directly from the command-line.

>> and the
>> distribution module is not really needed.
>> That just leaves the sandbox module.
>>
>> Does the sandbox module have any use as part of the proper component?
>>
>
> These are works in progress or works that depend on jars with third party
> incompatible licensing. Or perhaps works that are hard to test.
>
> It does not seem to be included in any releases - it is only present in SVN.
>>
>
> Right.
>
>
>> Would it be better as an actual sandbox component?
>>
>
> Depending on the licensing issue, they could be folded in the test jar.

The test jar should be for unit tests only.

>
>> Or if the classes are useful, perhaps they should be merged into core?
>>
>
> As noted above it depends on what to do with code that depends on a third
> party jar that has an incompatible license. The Java code is ASL 2 IIRC so
> the issue is whether it is OK to distribute code that depends on a third
> party jar which may have an incompatible license.

Depends.

It is possible to provide code to link to GPL code, so long as
downloading the GPL code is optional.
The component must be usable without the GPL code, i.e. it can depend
on it for optional functions only.

And of course the GPL code must not be distributed in releases.
So it ought to be OK to flag those jars as "provided"

However: is there anything in the Sandbox that warrants the extra work
to include the code in a release?
AFAICT, the code has not yet been included in any existing releases.

> Gary
>
>>
>> Note that Commons Net does not use modules, but does release its
>> examples separately, if that was still required.
>>
>> > Thank you,
>> > Gary
>> >
>> >
>> >
>> >>
>> >> Gary
>> >>
>> >>
>> >> On Thu, Jan 16, 2014 at 7:22 PM, sebb <[hidden email]> wrote:
>> >>
>> >>> At present, the VFS poms use the "apache-release" profile from the
>> >>> Apache pom, and override some bits of it that don't suit Commons.
>> >>>
>> >>> However, this is also done by the Commons parent pom which provides
>> >>> its own "release" profile.
>> >>>
>> >>> This is not ideal as VFS uses a different process for releasing code
>> >>> from all other Commons components.
>> >>>
>> >>> VFS is a multi-module project, which makes it a bit trickier to deal
>> >>> with assemblies etc.
>> >>>
>> >>> However as far as I can tell, it is relatively simple to fix VFS.
>> >>>
>> >>> Change VFS parent pom to disable the assembly plugin for itself and
>> >>> all inheriting poms
>> >>>
>> >>> Change VFS distribution pom to re-enable the assembly plugin and
>> >>> change the profile "apache-release" to "release"
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> E-Mail: [hidden email] | [hidden email]
>> >> Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: [hidden email] | [hidden email]
>> > Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Bernd Eckenfels
In reply to this post by sebb-2-2
Am Tue, 21 Jan 2014 16:10:35 +0000
schrieb sebb <[hidden email]>:

> I have done some work on this.I can fix up the poms so that the
> Commons "release" profile works.
> And it looks like the distribution module is not really needed. The
> assembly plugin can be run from the top level pom.

(sorry for picking this mail for quote, I wanted to stay within a
thread but it is not a specific answer to sebb)

 The current state looks pretty messed up. I have been trying to
debug some strange bundle-plugin behaviour but I could not really with
that complicated commons parent.

This parent is not really suited for multi-module builds and even if it
was it still does quite a few things too much IMHO. Would it be
possible to have a "policy commons" parent and a derieved parent which
also adds "build convinience"?

Currently the VFS project POM is building (unwanted and empty) JAR
files.

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Jörg Schaible
Hi Bernd,

Bernd Eckenfels wrote:

> Am Tue, 21 Jan 2014 16:10:35 +0000
> schrieb sebb <[hidden email]>:
>
>> I have done some work on this.I can fix up the poms so that the
>> Commons "release" profile works.
>> And it looks like the distribution module is not really needed. The
>> assembly plugin can be run from the top level pom.
>
> (sorry for picking this mail for quote, I wanted to stay within a
> thread but it is not a specific answer to sebb)
>
>  The current state looks pretty messed up. I have been trying to
> debug some strange bundle-plugin behaviour but I could not really with
> that complicated commons parent.
>
> This parent is not really suited for multi-module builds and even if it
> was it still does quite a few things too much IMHO. Would it be
> possible to have a "policy commons" parent and a derieved parent which
> also adds "build convinience"?
>
> Currently the VFS project POM is building (unwanted and empty) JAR
> files.

We could move the compiler and jar plugin into an own profile of the parent,
that is automatically activated if src/main/java exists. That, however,
enforces Maven 3 and standard layout for all Java projects.

Regards,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Bernd Eckenfels
Am Tue, 04 Feb 2014 21:53:24 +0100
schrieb Jörg Schaible <[hidden email]>:

> We could move the compiler and jar plugin into an own profile of the
> parent, that is automatically activated if src/main/java exists.
> That, however, enforces Maven 3 and standard layout for all Java
> projects.

Yes, I thought about this as well. I think this enforcing is not the
worst thing to do - but I guess you can also activate the profile in
your sub-pom if you insist on the wrong structure.

Or maybe the profile can be activated based on
build.sourceDirectory somehow? I guess all non-standard sub-poms have
to redefine that anyway.

This is a good thing to have. What about OSGi bundle
plugin? I am not sure if we need the pluginManagement
preconfiguration at all.

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Jörg Schaible
Bernd Eckenfels wrote:

> Am Tue, 04 Feb 2014 21:53:24 +0100
> schrieb Jörg Schaible <[hidden email]>:
>
>> We could move the compiler and jar plugin into an own profile of the
>> parent, that is automatically activated if src/main/java exists.
>> That, however, enforces Maven 3 and standard layout for all Java
>> projects.
>
> Yes, I thought about this as well. I think this enforcing is not the
> worst thing to do - but I guess you can also activate the profile in
> your sub-pom if you insist on the wrong structure.
>
> Or maybe the profile can be activated based on
> build.sourceDirectory somehow? I guess all non-standard sub-poms have
> to redefine that anyway.

No. Profile activations are evaluated before any property.

> This is a good thing to have. What about OSGi bundle
> plugin? I am not sure if we need the pluginManagement
> preconfiguration at all.

Does it harm?

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Bernd Eckenfels
Am Tue, 04 Feb 2014 23:20:45 +0100
schrieb Jörg Schaible <[hidden email]>:
> > This is a good thing to have. What about OSGi bundle
> > plugin? I am not sure if we need the pluginManagement
> > preconfiguration at all.
>
> Does it harm?

At least I dont get it to work in the VFS POM. A Stand-alone POM with a
test project works. I dont know what the reason is. Next thing to try
would be to remove the parent and inline all definitions so I can
remove them to see if it then works.

https://issues.apache.org/jira/browse/VFS-498

Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

sebb-2-2
Is the multi-module VFS pom really needed?

Commons Parent seems to work fine with single module poms.

On 4 February 2014 22:48, Bernd Eckenfels <[hidden email]> wrote:

> Am Tue, 04 Feb 2014 23:20:45 +0100
> schrieb Jörg Schaible <[hidden email]>:
>> > This is a good thing to have. What about OSGi bundle
>> > plugin? I am not sure if we need the pluginManagement
>> > preconfiguration at all.
>>
>> Does it harm?
>
> At least I dont get it to work in the VFS POM. A Stand-alone POM with a
> test project works. I dont know what the reason is. Next thing to try
> would be to remove the parent and inline all definitions so I can
> remove them to see if it then works.
>
> https://issues.apache.org/jira/browse/VFS-498
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

sebb-2-2
In reply to this post by Bernd Eckenfels
On 4 February 2014 20:25, Bernd Eckenfels <[hidden email]> wrote:

> Am Tue, 21 Jan 2014 16:10:35 +0000
> schrieb sebb <[hidden email]>:
>
>> I have done some work on this.I can fix up the poms so that the
>> Commons "release" profile works.
>> And it looks like the distribution module is not really needed. The
>> assembly plugin can be run from the top level pom.
>
> (sorry for picking this mail for quote, I wanted to stay within a
> thread but it is not a specific answer to sebb)
>
>  The current state looks pretty messed up. I have been trying to
> debug some strange bundle-plugin behaviour but I could not really with
> that complicated commons parent.
>
> This parent is not really suited for multi-module builds and even if it
> was it still does quite a few things too much IMHO.

Which things are excessive?
The intention was to use the pom for common items, and allow it to be
configured (with properties)/overridden by the component poms if
necessary.
But needing to override should be rare.

> Would it be
> possible to have a "policy commons" parent and a derieved parent which
> also adds "build convinience"?
>
> Currently the VFS project POM is building (unwanted and empty) JAR
> files.

What command are you using, and what are these jar files?

> Gruss
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Bernd Eckenfels
Hello,

Am Wed, 5 Feb 2014 09:55:18 +0000 schrieb sebb <[hidden email]>:

> On 4 February 2014 20:25, Bernd Eckenfels <[hidden email]>
> wrote:
> > Am Tue, 21 Jan 2014 16:10:35 +0000
> > schrieb sebb <[hidden email]>:
> >
> >> I have done some work on this.I can fix up the poms so that the
> >> Commons "release" profile works.
> >> And it looks like the distribution module is not really needed. The
> >> assembly plugin can be run from the top level pom.
> >
> > (sorry for picking this mail for quote, I wanted to stay within a
> > thread but it is not a specific answer to sebb)
> >
> >  The current state looks pretty messed up. I have been trying to
> > debug some strange bundle-plugin behaviour but I could not really
> > with that complicated commons parent.
> >
> > This parent is not really suited for multi-module builds and even
> > if it was it still does quite a few things too much IMHO.
>
> Which things are excessive?
> The intention was to use the pom for common items, and allow it to be
> configured (with properties)/overridden by the component poms if
> necessary.
> But needing to override should be rare.

Well, the main thing I noticed is, that the VFS-project (parent)
produces a target/osgi/MANIFEST.MF. There is a second antrun regarding
APIdoc. But other than that - looking at the build log again - it
seems not much more is actually executed.

> > Would it be
> > possible to have a "policy commons" parent and a derieved parent
> > which also adds "build convinience"?
> >
> > Currently the VFS project POM is building (unwanted and empty) JAR
> > files.
>
> What command are you using, and what are these jar files?

I was running mvn install, but I can no longer reproduce the problem.
With trunk rev. 1565946 and linux I dont see those JARs any more.
Have to check later if it is a windows related problem.

Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Fix up pom so it works with Commons release profile

Bernd Eckenfels
In reply to this post by sebb-2-2
Am Tue, 4 Feb 2014 22:55:57 +0000 schrieb sebb <[hidden email]>:
> Is the multi-module VFS pom really needed?

I think the project could be restructured to produce the examples and
make the distribution in a single module. However I personally like the
separation, especially as there are so many dependencies involved and
reducing the build time for that project should be a goal.

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]