On 09/12/2010 1:57 PM, Asmann, Roland wrote:
I don't like it. 2 Projects means that we have to share code somehow...
Besides, if it was just a simple JAR-file, it would be OK. We have about
7 modules, and I don't really feel like duplicating all of them.
You must have heard of libraries? Java runs on libraries
You put your code into projects that make JDK independent libraries.
Do not even think about duplicating source code. Very bad idea.
Your JDK dependent projects will very likely have no code at all and
only a few dependencies on your libraries, unless you have JDK dependent
modules for special test cases.
Besides, the only difference we really have is that we trigger Maven
with a different JDK, so we wouldn't even need profiles! I just don't
want to have 2 different versions for the project.
I think I'll try something with the invoker-plugin, that would at least
work for normal builds... Need to check it it would work on releases as
well...
If you like complexity, go ahead.
There is no need to make such a complex system.
Get it working with a simple structure and then after 6 months of
working your way around Maven with the simple set up then tackle some
optimization projects.
At least you will get your project working with Maven and start
optimizing with a working build that does what you want even if it is
not "optimal" (in your eyes at least).
Ron
On 09-12-10 19:23, Jon Paynter wrote:
good point there.
id opt for the simple solution too.
On Thu, Dec 9, 2010 at 10:18 AM, Ron Wheeler<rwhee...@artifact-software.com
> wrote:
> On 09/12/2010 1:08 PM, Jon Paynter wrote:
>
>> why 2 projects?
>> it seems 1 maven project with profiles and a batch script will work
>>
>> something like so:
>> mvn deploy -P SunProfileName
>> mvn deploy -P IBMProfileName
>>
> If it works, I would have no objection but 2 projects will work for sure
> and everyone knows how to set up a simple project.
> The same can not be said about profiles and they seem to encourage
complex
> solutions that generate lots of traffic and frustrated Maven users here.
>
> Sometimes it is a lot easier to do 2 simple things that are 90% identical
> than 1 complex thing that has no redundant code.
>
> Ron
>
>
> On Thu, Dec 9, 2010 at 5:15 AM, Ron Wheeler
>> <rwhee...@artifact-software.com>wrote:
>>
>> On 09/12/2010 7:52 AM, Asmann, Roland wrote:
>>>
>>> On 09.12.2010 11:29, Stephen Connolly wrote:
>>>>
>>>> you need to add an exclusion on the dependency that is being
brought in
>>>>> by
>>>>> profile activation.
>>>>>
>>>>> It was a mistake that profiles include the<dependency> section as
>>>>> there
>>>>> is
>>>>> all manor of issues.
>>>>>
>>>>> The profile gets activated based on the environment where maven is
>>>>> running,
>>>>> not the environment where the artifact is deployed.
>>>>>
>>>>> If you have 3rd party deps that use profile activation to pull in
>>>>> dependencies, you will need to define exclusions on those
>>>>> dependencies...
>>>>> that will stabilise your build.
>>>>>
>>>>> If your build uses profile activation to pull in dependencies,
that is
>>>>> your
>>>>> bad, take it out
>>>>>
>>>>> -Stephen
>>>>>
>>>>> No, this is NOT the solution, since I will need the artifact on both
>>>>> SUN
>>>>>
>>>> and JDK machines. The problem is that when I build with only one of
>>>> those, I can also only deploy it to one of those! Therefor, I need to
>>>> build one artifact with IBM JDK, which will then be deployed to
the IBM
>>>> JDK server, and one with SUN, which will likewise be deployed to
the SUN
>>>> server.
>>>>
>>>> I understand that I can build both versions on either JDK by either
>>>> adding or excluding dependencies, the fact is that I don't want to do
>>>> this manually, but let Maven handle it (as it can!) depending on which
>>>> JDK I build.
>>>>
>>>>
>>>> Like I said before, the real problem is that I want to have my release
>>>
>>>> build BOTH artifacts at once, and I am not sure how I could
achieve this
>>>> goal...
>>>>
>>>> 2 maven projects and a batch script.
>>>>
>>> Ron
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
